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ABSTRACT 

The Consultative Committee for Space Data Systems 
Recommendations for Packet Telemetry and 
Advanced Orbiting Systems (AOS) propose standard 
solutions to data handling problems common to many 
types of space missions. The Recommendations 
address only space/ground and space/space data 
handling systems. Goddard Space Flight Center’s 
AOS Testbed (AOST) Program was initiated to better 
understand the Recommendations and their impact on 
real-world systems, and to examine the extended 
domain of ground/ground data handling systems. 

Central to the AOST Program are the development of 
an end-to-end Testbed and its use in a comprehensive 
testing program. Other Program activities include 
flight-qualifiable component development, 
supporting studies, and knowledge dissemination. 

The results and products of the Program will reduce 
the uncertainties associated with the development of 
operational space and ground systems that implement 
the Recommendations. The results presented in this 
paper include architectural issues, a draft proposed 
standardized test suite and flight-qualifiable 
components. 

Key words: AOS Testbed, CCSDS, service and 
network management, SOSDU, testing, flight- 
qualifiable components. 

1. INTRODUCTION 

Goddard Space Flight Center’s (GSFC’s) Advanced 
Orbiting Systems (AOS) Testbed (AOST) Program 
provides the bridge between development and 
widespread use of the Consultative Committee for 
Space Data Systems (CCSDS) Recommendations for 
Packet Telemetry and AOS (Refs. 1-2). The 
Recommendations, which will be used by future 
NASA missions, offer the promise of significantly 
reducing mission life-cycle costs by standardizing 
data handling interfaces in both space and ground 
systems. Standardization allows the reuse of 
hardware and software, and facilitates agency 
interoperation in national and international programs. 

The AOST Program is using a multi-faceted approach 
that will reduce the remaining costs and risks 
associated with the use of the Recommendations by 


NASA. This paper presents results and products of 
AOST Program activities to date (November 1992). 
The results and products have significant implications 
with respect to the development of systems built in 
accordance with the CCSDS Packet Telemetry and 
AOS Recommendations. 

2. AOST PROGRAM OVERVIEW 

This paper is a companion paper to (Ref. 3), which 
provides a detailed description of the AOST Program. 
A high-level overview of the Program is given in this 
section to provide a context for the discussion of 
activities and results to date. Readers interested in a 
more comprehensive description of the AOST 
Program, its goals, objectives, and work activities are 
referred to (Ref. 3). 

The AOST Program comprises five work activities: 
developing and using the AOST, developing flight- 
qualifiable components, conducting a test program, 
performing supporting studies, and disseminating the 
knowledge gained and products developed through 
Program activities. Detailed descriptions of these 
activities are presented in (Refs. 3-4). 

The services defined in the Recommendations are 
being implemented in the AOST to demonstrate that 
there is at least one technically feasible, economically 
acceptable solution for providing each service and to 
perform real world validation of ground implement- 
ability in technology, operability, and manageability. 
It is not intended that the AOST select a particular 
design solution for CCSDS services. The AOST 
contains multiple implementations of many of the 
CCSDS services, providing a platform for testing 
alternative design solutions through which critical 
information can be provided to program management, 
industry, and the CCSDS. 

The AOST is being developed as a series of four 
Capabilities, each distinguished by the CCSDS 
services and functions provided. The AOST 
comprises all of the subsystems of an end-to-end 
CCSDS-based data handling system, and includes 
both space and ground elements. Capability One 
(C-l) space elements include an instrument simulator 
and a frame generator that creates Virtual Channel 
Data Units (VCDUs). Ground systems include a 
front end, multiple service processors, and, in 
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Capability Two (C-2), a communications address 
processor and service and network management 
elements. The ground system elements process the 
VCDUs generated by the space elements to provide 
the CCSDS service(s) designated by the end user via 
the service and network management elements. 

3. ACTIVITIES TO DATE 

The AOST Program has produced a number of 
documents in support of Program activities. These 
documents establish Program goals and approach, 
allocate functions to space and ground system 
elements, define Testbed interfaces, and represent 
initial development efforts in service and network 
management. The AOST Program Plan (Ref. 4) 
defines the goals and objectives of the Program and 
the technical approach to achieving those goals and 
objectives. The Program Plan also summarizes the 
allocation of functions to the Testbed space and 
ground system elements. The Interface Definition 
Documents (Refs. 5-9) and the Space Operations 
Service Data Unit (SOSDU) Format Definition 
Document (Ref. 10) define the internal and external 
data and protocol interfaces of the Testbed. Draft 
specifications for service management interfaces with 
ground system elements (Refs. 11-12) define the 
management interfaces that support efficient use of 
resources and systems. 

The C-l AOST delivered in March 1992 provides 
three CCSDS AOS services: Virtual Channel Access 
(VCA) service.VCDU service, and Path Packet 
service. The AOST team established and 
documented ground rules governing the implementa- 
tion of these services in C-l (Ref. 13). 

Functional testing of the C-l AOST is still in 
progress. Research testing will be initiated upon 
completion of functional testing. The Master Test 
Plan (Ref. 14) and C-l Test Plan (Ref. 15) define the 
general test program and the C-l test program, 
respectively. The C-l test program has produced a 
number of findings, most of which have been specific 
in nature and related to software debugging rather 
than issues related to the CCSDS Recommendations. 
A few significant issues have been identified and are 
addressed in this paper. The test program is also 
supporting the development of a suite of standard 
conformance and compatibility tests for use by 
CCSDS system developers. 

The European Space Agency (ESA), Canadian Space 
Agency, National Space Development Agency of 
Japan, and the Deep Space Network Prototyping 
Laboratory at Jet Propulsion Laboratory (JPL) have 
expressed interest in cooperative testing using the 
AOST. A draft test plan for joint testing using the 


AOST and ESA’s Space Data Network Testbed is 
currently under review by NASA and ESA (Ref. 16). 

The development of flight-qualifiable components is 
well ahead of schedule. A preliminary specification 
has been issued for a Reed-Solomon (R-S) encoder 
chip (Ref. 17). 

Several members of the AOST Program team are 
supporting the CCSDS and the Space Operations 
Services Infrastructure (SOSI) working group. The 
SOSI group is a joint GSFC/JPL team that is 
developing service and operations concepts and 
identifying cross-support points, protocols, and 
formats common to all NASA implementations of 
CCSDS services (Ref. 18). 

A library of AOST Program and related documents 
has been established as a central repository of 
knowledge gained and products of the AOST 
Program. The first “Workshop for CCSDS 
Implementors” was held at GSFC on November 4-5, 
1992, under the sponsorship of the AOST Program. 
The Workshop was attended by more than 300 people 
representing 44 U.S. companies, the Department of 
Defense, 2 universities, 4 NASA centers, and NASA 
Headquarters. 

4, RESULTS 

The results of the AOST Program to date apply to 
three different aspects of the Program: the AOST 
architecture, a draft proposed standardized test suite, 
and flight-qualifiable component development. 
Findings related to the AOST architecture were 
identified through the development process and C-l 
test program. The proposed test suite is a product of 
the C-l test program. One of the flight-qualifiable 
components has been baselined by two GSFC 
missions. 

4.1 Architecture 

The architecture-related findings discussed in this 
section have resulted from the C-l AOST develop- 
ment process and subsequent C-l test program. Of 
primary importance are the ground rules identified to 
govern the AOST development process, the SOSDU 
format, service and network management, AOST 
scheduling and configuration, and latencies induced 
by the selected implementation of the AOST 
architecture. 

4.1.1 Ground Rules 

Ground rules (Ref. 13) for data processing were 
identified early in the C-l development process as 
part of the developers’ set of requirements. The 
domain of the CCSDS Recommendations ends at the 
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space/ground interface; the Recommendations do not 
address the requirements for implementing a ground 
system. The ground rales are needed to standardize 
ground/ground interfaces and ground processing 
among multiple implementations of the CCSDS 
services. The ground rules cover parameterization of 
data, processing requirements related to data 
characteristics, and processing requirements related 
to error conditions. While the AOST ground rules 
have not yet been proposed for adoption by die 
CCSDS community, it will be necessary to adopt 
some common set of ground rules, or for similar 
ground rules to be incorporated into a CCSDS 
Recommendation. 

4.1.2 SOSDUs 

The SOSDU data structure (Ref. 10) “extends” the 
CCSDS Recommendations to ground system 
interfaces. The SOSDU allows for the process- 
oriented decommutation of CCSDS data structures 
while preserving the service types and providing a 
mechanism for the incorporation of metadata related 
to the processing of the CCSDS data. The SOSDU 
header currently contains a generalized label and a 
SOSDU label common to all SOSDUs, a set of 
service parameters specific to each of the CCSDS 
services, and optional agency- and/or network- 
unique fields. The SOSDU is in an early stage of 
development and is expected to change significantly 
within the next several months. The SOSI group is 
identifying SOSDU requirements based on a global 
perspective of cross-support points, protocols, and 
formats. 

4.1.3 Service & Network Management 

AOST Service Management will explore ways to 
improve the efficiency of network operations and 
resource utilization in networks providing CCSDS- 
based services. Currently, ground systems handling 
space data are geared to scheduled, circuit-switched 
communication services. The ability to trace end-to- 
end data flows and determine system performance is 
largely dependent on verbal reporting mechanisms 
and operator intervention. Problems are usually 
detected and reported first by end users. The users 
must be familiar with the operation of the ground 
infrastructure to make use of the system’s 
functionality. 

The Service Management system being developed for 
the AOST (Refs. 11-12) allows users of a CCSDS 
service-providing network to interact with that 
network in terms of services rather than equipment 
configurations, and manages the equipment config- 
urations of multiple facilities and subnets. AOST 
Service Management distributes service configuration 
information, generates periodic reports about the 


quality of services, and monitors network elements 
for fault isolation. The AOST Service Management 
function will provide greater fault detection, 
isolation, and recovery capability for CCSDS data 
services. 


AOST Service Management uses a distributed 
hierarchical architecture comprising a central 
Network Management Integrator and Coordinator 
(NMIC), multiple Complex Managers, and their 
associated managed systems. The AOST Service 
Management hierarchy is illustrated in Figure 1. 
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Figure 1. Service Management Hierarchy 

The NMIC interfaces with the user community and 
coordinates the services provided by multiple com- 
plexes. Each Complex Manager manages the opera- 
tion of a single complex, such as a subnetwork, 
facility, or administrative domain. Complex 
Managers manage local equipment as well as 
services. The systems comprising a complex must 
each support an agent that translates the local 
representation of information into a global 
representation and standard management protocol 
used by the Complex Managers and the NMIC. The 
AOST NMIC and Complex Managers are being 
implemented using SunNet Manager, a commercial 
off-the-shelf network management product 
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Managed systems comprise two conceptual 
components: the data processor, which performs the 
actual processing and presorts the agent with a local 
representation of managed parameters: and the agent, 
wMch translates the management information 
between the local representation and a global 
representation understood by the Complex Manager. 
The agent presents the Complex Manager with a view 
of the processor as a collection of abstract functions 
and system operation parameters. 

The AOST is developing and testing a demonstration 
version of a standard Management Information Base 
(MIB) for CCSDS services that can be used by other 
CCSDS-compliant systems. The MIB includes the 
CCSDS AOS, Packet Telemetry, and Telecommand 
(Refs. 19-21) services and protocols, including 
configuration and performance information, and 
allows the NMIC, Complex Managers, and managed 
systems to exchange management information in a 
common, standard language. 

4.1.4 Scheduling/Configuration of the AOST 

The CCSDS Recommendations assume data-driven 
rather than scheduled space data systems. However, 
all of the C-l AOST elements require some degree of 
pre-configuration prior to receiving data. Each time 
the data parameters change (e.g., a new Spacecraft ID 
or a different CCSDS service is used), each element 
must be reconfigured. Typically, reconfiguration is 
accomplished by loading a pre-defined catalog from 
disk to memory. If a new configuration is being 
used, a new catalog must be manually constructed, 
stored on disk and loaded into memory. This is a 
time-consuming process that is subject to error. 

The loading of catalogs consistent with the expected 
data stream requires prior knowledge of the data 
characteristics and is a form of system scheduling. 

To simplify AOST operations in C-2, reconfigura- 
tions will be performed by the automated AOST 
service management system. The AOST will still be 
“scheduled,” but from a centralized location. 

A solution under consideration by the AOST is the 
use of adaptive frame synchronizers that would 
automatically determine the frame length of incoming 
data, the presence/absence of R-S coding, and that 
would identify the data by examining the Version ID 
and Spacecraft ID fields in the frame header. The 
result would be a truly automatic, data driven system. 

4.1.5 Data Latency 

Some of the elements in the AOST have been 
developed using a “pipeline” architecture. Incoming 
data are used to “push” data previously received 


through the system. In the AOST environment, this 
pipelining occurs at the frame level, introducing 
unpredictable data latency. At the close of any data 
transmission (such as at Ioss-of-signal), the last 
several frames received will lie dormant in the system 
until they are manually “flushed” flushed after a 
system time-out, or when frame sync lock is 
reacquired at acquisition-of-signal. In the third case, 
data output from system upon reacquisition contains 
one or more data units that represent “old” data and 
some that represent “new” data, resulting in unusual 
and unpredictable latency. 

Although unpredictable latency may not be 
significant to many applications, it is unsuitable for 
supporting real-time, interactive operations such as 
“joysticking.” Constant latency is more important 
than low latency in joysticking operations because the 
operator needs to be able to reliably predict the 
response time of the system. Data latency that varies 
unpredictably by orders of magnitude may have 
serious operational consequences. Operational 
systems having requirements for constant or low 
latency must avoid a pipelining architecture. 

4.2 Test Suite 

An important product of the AOST Program will be 
the suite of tests that is being developed (Ref. 22). 
The test suite will be available to organizations 
wanting to test their existing or new CCSDS-based 
systems, and will serve as the basis for the 
conformance and compatibility test suite identified as 
an AOST Program objective (Ref. 4). The test suite 
does not currently address performance testing. 

The proposed draft test suite is organized in terms of 
the 22 functions and 8 services defined in the CCSDS 
AOS Recommendation (Ref. 2). The functions can 
be divided into data generation functions 
(transmitting) and corresponding data processing 
functions (receiving). Specific groupings of these 
functions comprise procedures that in turn comprise 
the CCSDS services. Each function may support 
multiple procedures and services. Examples of 
functions include fill generation, VCDU 
commutation, and frame synchronization. Examples 
of procedures include Channel Access, Packet 
Transfer, and Bitstream. Examples of services 
include Virtual Channel Access and Path Packet A 
complete listing of the functions, procedures, and 
services can be found in (Ref. 22). 

The test suite provides a framework of standard tests 
to verify the compliance of any given implementation 
with the CCSDS Recommendations. Users may 
select from among the standard tests to accommodate 
the particular services and function-to-element 
allocations of their system implementations. Testing 
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occurs at the function level After successful testing, 
the functions can be grouped into procedures and 
services which are then tested at the procedure or 
service level This approach assumes that each 
service has been implemented using the previously 
rested functions as “building blocks.” The 
alternative, in which each function is implemented 
separately for each service, would require 
independent testing for each function supporting each 
service. 

The CCSDS Recommendations do not detine or 
standardize the parameters or services used by each 
implementation. Rather, the Recommendations 
define only the data structures and delimiters for the 
services. Each flight project is free to choose which 
services it will support, which virtual channel IDs and 
application process IDs will be used, and what 
combinations of services and parameters will be 
permissible. The standardized test data suite may 
lead to a test data set generation capability that will 
permit users to select the functions and services to be 
tested, the particular data specifications for each 
implementation, and specific parameters such as 
Spacecraft IDs, sequence counter starts, etc. The end 
product of such a data set generation capability would 
be a test data set consistent with the CCSDS 
Recommendations that is tailored to the particular 
implementation being tested. 

4.3 Flight-Qualifiable Components 

Three CCSDS -based flight-qualifiable components 
are being developed: 

• Reed-Solomon Decoder Chip Set 

• Reed-Solomon Encoder 

• Packetizer 

The R-S Decoder Chip Set comprises four, fully 
custom VLSI chips using a Euclid algorithm. The 
Decoder Chip Set was produced by a commercial 
foundry and cannot be flight-qualified (Ref. 23). It 
corrects a maximum of 16 symbols at a sustained rate 
of 80 Mbps. The next-generation flight-qualifiable 
decoder is being developed as a single chip 
encoder/decoder. The new chip set will be flight- 
qualifiable and will perform 1 to 16 symbol error 
corrections at a sustained data rate of 150 Mbps. 

The flight-qualifiable R-S Encoder features a 
selectable interleave depth (1 to 8) and supports a 
sustained data rate of 200 Mbps (Ref. 17). This 
Encoder is currently available for flight project use, 
and has been baselined by the Tropical Rainfall 
Measuring Mission and the X-ray Timing 
Experiment. 


The Packetizer is currently being defined. The 
Packetizer will create CCSDS Packet headers and 
will support variable or fixed length packets from 64 
bytes to 2K bytes. The Packetizer will provide for a 
10 MHz input date rate and a 20 MHz output data 
rate. A preliminary specification is being drafted and 
will be available in December 1992. 

5. SUMMARY 

The AOST Program is making significant progress 
towards its goals of supplying information to ground 
and flight programs, to industry, and to the CCSDS; 
developing a conformance and compatibility test 
suite; and promoting the use of the CCSDS 
Recommendations for Packet Telemetry and AOS by 
flight projects. Architecture considerations, including 
ground rules, a ground/ground data transfer 
mechanism, service and network management, 
scheduling, and latency are emerging from the AOST 
development process and C-l test program. 
Additional lessons will result from the continuation 
of the C-l test program and the initiation of the C-2 
AOST development process. A proposed test suite 
has been drafted and will be updated and revised as 
work on the AOST Program continues. Flight- 
qualifiable components are being developed and 
prepared for flight-qualification by flight projects. 
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